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Buddy Chat Invitation 



Buddy Chat 



Invitation Message: 



1000 



Screen names to invite (separated by commas): 




Join me in this Buddy Chat. 



Buddy Chat room: jag ChatOO 



The people to whom you send this invitation may warn you in return. 









Cancel 


Help 


send 
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FIG. 10 
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WARNING! You have received a file transfer request! If 
you don't know who is sending you this file, be cautious; it 
could contain a computer virus. Computer viruses can destroy 
your work and even damage your computer. 

AOL histoid Ife^ Center: 

How can I protect my computer? 

1 . Get anti- virus software, and use it. 

2 . D orit op en file transfers from strangers . 

3. Update your anti- virus software regularly. 

4. Make back-ups of your important files regularly. 

5. Run your own virus- check on any file someone sends you. 

6. If you exchange floppy disks, virus- check your floppies. 

Some Leading Anti-virus Software: 

Norton Antivirus V5.0 for Windows 95/98 
VirusScan Classic V4.0 

Dr. Solomon's Anti- Virus Deluxe Windows 95/NT 




FIG. 14 
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MANAGING NEGOTIATIONS BETWEEN 
USERS OF A COMPUTER NETWORK BY 
AUTOMATICALLY ENGAGING IN 
PROPOSED ACTIVITY USING 
PARAMETERS OF COUNTERPROPOSAL OF 
OTHER USER 

TECHNICAL FIELD 

This invention relates to managing communications 
between users of a computer network. 

BACKGROUND 

The rapid emergence of the Internet and the World Wide 
Web has created an environment in which anybody in the 
world who can connect to the Internet through a personal 
computer is generally able to access the universe of infor- 
mation that is available via Web sites. Electronic mail (a.k.a. 
e-mail) has also become ubiquitous due to its ease of use and 
its low cost. The emergence of these capabilities has been 
spurred by technological advances in various areas, includ- 
ing microprocessors (both computing speed and 
miniaturization), computer operating systems and interfaces 
(e.g., Windows, Macintosh, and Unix), and Internet brows- 
ers (e.g., Netscape Navigator). In turn, the rapidity of 
increase of the technology has had a direct positive impact 
upon productivity, and the world economy in general. Thus, 
there is an incentive for high-tech entities to create further 
improvements in the state of the art with respect to the 
Internet. 

An online forum is a communications interchange in 
which people may communicate with others through suc- 
cessive electronic transmissions between respective com- 
puter systems. An online forum, or any other type of 
distributed computer services, may be implemented on a 
distributed computer system such as that shown in FIG. 1. 
Forum participants (equivalently, users of the computer 
services) typically are scattered across a large geographical 
area and communicate with one or more central server 
systems 100 through respective client systems 102 (e.g., a 
personal or laptop computer). In practice, the server system 
100 typically will not be a single monolithic entity but rather 
will be a network of interconnected server computers, pos- 
sibly physically dispersed from each other, each dedicated to 
its own set of duties and/or to a particular geographic region. 
In such a case, the individual servers are interconnected by 
a network of communication links, in known fashion. One 
such server system is "America Online" from America 
Online Incorporated of Virginia (AOL). 

Each client system 102 runs client software that allows it 
to communicate in a meaningful manner with corresponding 
software running on the server system 100. The client 
systems 102 communicate with the server system 100 
through various channels, such as a modem 104 connected 
to a telephone line 106 or a direct Internet connection using 
a transfer protocol such as Transfer Control Protocol/ 
Internet Protocol (TCP/IP). The server system 100 is respon- 
sible for receiving input from the client systems 102, 
manipulating the collective body of input information (and 
possibly information from other sources) into a useful 
format, and retransmitting the formatted information back to 
one or more clients 102 for presentation on an output device, 
such as a display screen. 

A specific aspect of the Internet "culture" is the "chat 
room" phenomenon. Achat room is a virtual space (i.e., an 
electronic channel) in which some specific communications 
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activity is ongoing. In some cases, the activity is an 
application, such as a computer game. In many other cases, 
the activity is a simple conversation, or "chat session", 
between the participants. Referring to FIG. 2, a chat room 

5 200 is illustrated, in which the various participants 204 (e.g., 
"Allens9", "JOSHUAALEX", etc.) may enter text which 
appears in a scrolling text window 202 on each participant's 
computer display screen. In the example in FIG, 2, the chat 
room 200 has 22 participants whose identities (or "screen 

1Q names") are listed in a scrolling window 210. A participant 
204 may respond to the comment of another participant 204 
by entering a line of text in an edit box 206 and activating 
(e.g., by clicking with a pointer device, such as a mouse) a 
SEND button 208. In response, the text in the scrolling text 

15 window 202 scrolls upwards and the newly entered line of 
text is displayed at the bottom of the scrolling text window 
202. In the illustrated example, the last participant to enter 
a comment was JOSHUAALEX, who typed "TEXAS". 
The chat room 200 shown in FIG. 2 is "public", meaning 

20 that it is generally open to any user of the online service who 
accesses it, and it typically has multiple participants who 
were placed in the chat room by the computer-service 
provider and who most likely never have met or conversed 
with one another before. A comment by a participant in a 

25 public forum may be seen by all of the participants of the 
chat room. If a participant desires some privacy, that par- 
ticipant may open and enter a "private" chat room (for 
example, by clicking on a "Private Room" button 212), and 
thereafter invite one or more other participants to enter the 

3 0 private chat room, which can be accessed exclusively by the 
originators and their invitees. Once in a private forum, 
participants may communicate with one another without fear 
that uninvited participants will be able to see their com- 
ments. It is also possible to have a semi-public chat room, 

35 which is open to a specified group of users. 

AOL has created the AOL Instant Messenger (AIM™) 
system. The AIM system allows a user to create an electronic 
messaging medium known as a "Buddy List"™ of others 
(such as friends and family) with whom the user often 

40 interacts while online and send instant messages (IMs) to 
those users. The AIM system automatically informs the user 
whenever a member of that user's buddy list is online. Thus, 
the two buddies can communicate directly (i.e., chat) 
because they both are online and are aware of each other's 

45 presence. 

Another development by AOL in this arena is the concept 
of "Evil". This concept arose in recognition of the fact that 
users can and do abuse the privileges afforded them by the 
abilities to communicate instantly with others and to trans- 

50 mit large volumes of information. Such abuse may occur, for 
example, when a user sends messages having objectionable 
content, or when a user overuses the AIM system by sending 
excessive numbers of messages to other users. Another form 
of abuse occurs when a user sends files that contain large 

55 amounts of data to another user, so that when the recipient 
tries to open or download the files, or even perform other 
activities, the recipient's computer system is slowed down 
due to the processing of the received files. 

AOL's creation of the Evil concept is an attempt to 

60 remedy this and other types of abuse. If a user perceives that 
another user is behaving badly (e.g., repeatedly sending 
unwanted IMs), the offended user can "evil", or warn, the 
misbehaving user, thereby increasing the misbehaving 
user's Evil level. The effect of eviling a user typically is 

65 small but cumulative. Over time, if a user has been eviled a 
sufficient number of times, that user's ability to use system 
resources (e.g., send IMs) will be deliberately slowed as a 
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punishment. If the abuse continues and even more eviling If a counterproposal is made, a further response to the 

occurs, the abuser eventually can be involuntarily logged off counterproposal can be made, and this response also can be 

the computer network. The underlying notion is to promote an acceptance, a rejection, or yet another counterproposal, 

computer etiquette and basic courtesy in the online (and This sequence may occur indefinitely until acceptance or 

particularly chat room) environment. Giving users the power 5 rejection occurs. 

to "evil" one another gives them the ability to create a a cancellation of a proposal or counterproposal may be 

self-policing society, thus alleviating the Internet Service issued by the user that originally made the proposal or 

Provider (ISP) from having to perform the policing function. counterproposal, so long as this occurs prior to the receipt of 

Further details on eviling techniques can be found in U.S. a response. Typically, such a cancellation should include a 

Ser. No. 09/076,483, filed May 13, 1998 now U.S. Pat. No. 10 reason for the cancellation. 

6,336,133, entitled "Regulating Users of Online Forums", In ^ a rejection a user may indicate mat the pro . 

and U.S. Ser. No. 09/076,484, filed May 13, 1998 now U.S. , fe ^ . J nored dthef ^ Qr ^n^/ft 

Pat. No. 6,339,784 entitled "Self-Policing, Rate Limiting inaction). 

Online Forums", both of which are incorporated by refer- — , 4 , „ t t . t _ 

ence 15 e P rotoc °l a U 0WS users to transmit messages, referred 

to as "Evil" messages, registering displeasure with any 

Although.it is possible for a chat room to be completely proposal, counterproposal, or acceptance. An Evil message 

free-form dialogue on any subject, it is common for chat has a cumulative (and potentially exponential) effect upon a 

rooms to be organized around a specific subject for discus- recipient's ability to access the computer system's 

sion. The proliferation of the chat room phenomenon has resources 

created a need for a mechanism to optimally arrange a chat *° Qne objective of , he CQ , is tQ hd onUne ^ 

room environment to meet the needs of the users. For duce m ima[ environmenl for an activ f, 5 enablj 

example, a given user might desire to have a private con- ^ , 0 iate the meteR of the activit ^ » 

versation with a specific group of three other users on a mm h rea * hed ^ ac(ivities indude exch ' an £ f oice 

particular subject. Alternatively, the user might wish to play ffl , f „ onljne findi a rout f fr * m one 

a particular computer game jointly with two friends, each 25 ^ ^ {q & transferri flles> direct insum 

located at a different remote site. Presently, if such a user ™c™™\w^o™™ ,„i„ ■„ ~ „u nt m 

. , ^ . , . . . ; ' ... . messaging, exchanging avatars, participating in a chat room, 

wishes to engage in such activity, the user can either 1) find nr „■„ „ J„ . 

f & , .jj ... ' . or engagmg in collaborative project development, 

an existing chat room where the desired activity is ongoing * , • i ■ • , 

and attempt to join in, but not necessarily having any control n A " other P otential ° lUme acUv,t y tnat fi 11 make ° f lh f 

over the identities or number of other participants; or 2) send 30 Rendezvous protocol is e-commerce. The protocol lends 

an IM or e-mail message to the other users with whom the rtself to a negotiationof a sale/purcbase of goodsor services, 

user wishes to engage in the activity and invite them to do or . f m * M ° P' 0 ^ Parameters of such a negotiation 

so. Typically, the inviting user will receive either no mi 6 h ^ally i°chide price, model, style, color, dehvery 

response at all (e.g., if the recipient ignores the invitation) or detalls - and warrant y de,ails - 

a binary response (i.e., yes or no) to the invitation. 35 A rejection message may indicate a reason for the rejec- 

i i- l. c .u t .i. . • . lion. TVpical reasons include the following: the proposed 

In light of the foregoing, the present inventors have .• •. • . JU i- . . • . J 

• i ,i ac j i j a ui • • .• activity is unsupported by a client computer associated with 

recognized the need for a powerful and flexible negotiation . . C .S V '. v . . . . . , 

mechanism, whereby users desiring to communicate or * reC1 P ient of he ^ h °P 0Sal; the P r0 P 0Sed ' ^vity was denied 

otherwise interact with each other cln "bargain" with one b * ?. re ? 1 P! ent of , P ro P osal ; a ' eci P ient f ! he P ro P osaI 

another in order to agree ultimately upon a mutually accept- 40 l f 0:cd the P ro P OSal ; * e P r °P°f al < imed out; or 

able communication (e.g., chat room) or other interaction P ro P OSal messa S e °° uld no1 be ™ derst ° od - 

(e.g., multiple user computer game) context. In one embodiment, the Rendezvous protocol is imple- 
mented as computer software potentially within a larger 

SUMMARY computer software application. The protocol software is 

, , . . i , . u* *• r.u 45 tangibly embodied in a computer-readable medium or 

Implementations may include various combinations of the \ , , ^ A , ^ 

followine features propagated earner signal. The protocol software contains 

s t t tm „ , . instructions to allow the computer system to conduct an 

A protocol, referred to as the "Rendezvous protocol, is onlme negotiation 

designed to facilitate interactions between users of a com- t^*,. j u- j ujl 

4 i • . c A , . r The techniques and mechanisms described here may 

puter network by transmitting a first user s proposal for an < n j r *u c n j t-u 

tt. <i 1 j 50 provide one or more of the following advantages. The 

activity to another user. The proposal may include one or „ , , . , tl _ t 

J . j ... c * j 4 . . Rendezvous protocol provides users with the ability to 

more parameters descriptive of the proposed activity. A r t u * • *■ r r • 

r , r 4 • ^ negotiate characteristics ot an interactive online environ- 

response, such as an acceptance, a rejection, or a * / u * v * \ a i* 

r . , . ,/ 4 L iL j- ment (chat session, online game, etc.). As a result, users can 

counterproposal, is received from the other user. Depending . v , t • \. ■ 7- - . ,C A iL 

, i • j t . .t tailor and optimize their online environments so that they are 
on the received response, the users may or may not selec- « * n L1 t „ ^. . , . \. 
... ■ .u j ■* 55 mutually agreeable to all participants. This optimization 
tively engage in the proposed activity. • n * * ■ • . j 
' r ' typically occurs prior to inception of the environment under- 
One such activity could be an online "chat" session, and going negotiation. Consequently, users can engage in envi- 
a typical set of parameters for a proposal to chat could ronments of their own choosing and according to their own 
include a proposed topic on which the chat session will be desircs> and without encountering unwanted or undesirable 
focused and a proposed channel in which the chat session 60 circumstanccs or participants. 

will take place. Another typical activity could be an online features and advantages will be apparent from 

computer game, and the specified parameters could identify ^ foUowi description, including the figures and the 

proposed participants in the game. claims 

An acceptance indicates agreement to all parameters of 

the proposal. A rejection indicates disagreement with at least 65 BRIEF DESCRIPTION OF THE DRAWINGS 

one parameter of the proposal. A counterproposal indicates FIG. 1 shows a prior art distributed computer system of 

an offer to modify one or more of the proposal parameters. the type used for providing online computer services. 
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RG.2 is a screen shot showing an example of a prior art particular activity under specific circumstances for example, 

online computer chat room forum. playing a computer game with certain other players, or 

FIG. 3 is a flowchart illustrating a protocol for a nego- discussing a particular subject in a private chat room, 

tiation process Rendezvous uses "flea market-style" negotiation as a model 

. ' . . 5 for negotiating parameters of the interaction environment. 

FIG. 4 is a table of state transition values. olherS) ^ ^ of parameters that ^ns may wish 

FIG. 5 is a diagram illustrating the data format of a to control include the number of other participants and the 
negotiation protocol message. identities of those participants. For example, perhaps a user 
FIG. 6 is a table of data values for data fields in a enjoys playing bridge while online, but only with three 
negotiation protocol. 10 specific individuals; or perhaps a user desires to communi- 
ng t * » ui c * c tiv a u *u- cate with other computer game enthusiasts about a new 
FIG. 7 is a table of parameters for a TLV field within a Q ^ ^ Re P ndezv f 0US toco , allows a ^ tQ 

negotiation protocol message. propose a comraunication session subject t0 such param . 

FIG. 8 is a diagram illustrating a data format of a Client eters. Further, Rendezvous allows recipients of such pro- 
Error message. posals not only to accept or reject the proposal, but also to 

FIG. 9 is a table of data values for a Client Error Code data 15 respond with a counterproposal that modifies one or more of 

field, the proposed parameters. 

FIG. 10 is a screen shot showing an example of how a The Rendezvous protocol serves as the underlying struc- 

Chat proposal message appears to the online computer user mre ° f %)f ^ m ' $ ^ m ™™& betw *f D bu £ dies 

who originates the proposal 1D system is referred to as an Inter-Client Basic 

" " " 20 Message, abbreviated ICBM. ICBMs are said to contain 

FIG. 11 is a screen shot showing an example of how a "payloads," which hold the informational content of an 

Chat proposal message appears to the online computer user ICBM. An Instant Message (IM), which effectively is like an 

who receives the proposal. e-mail message that will be instantly displayed to the 

FIG. 12 is a screen shot showing an example of how a recipient, is an example of an ICBM pay load. In general, a 

Client Error (rejection) message appears to the online com- 25 Rendezvous-based message is another example of an ICBM 

puter user who rejects the proposal. pay load. (It is noted that there is one type of Rendezvous 

ii • u * u • i r u message, a Client Error message, to be described below, 

FIG. 13 is a screen shot showing an example ol how a , . 7° . t ,,™w \ 

™. t c / • «■ \ ♦ .u i- which is not an ICBM.) 

Client Error (rejection) message appears to the online com- A .. , , ' , . . r , iTU , 

. u ■ ■ • j #u JL iu- t j As discussed above, one characteristic of the AIM system 

puter user who originated the proposal being rejected. . t . , „ . * tl _ A . . 4 / . 

r 43 t? j ^ is the ability to evil another user. A user might employ the 

FIG. 14 is a screen shot showing an example of how a File ev [\ capability against another user in an instance in which 

Transfer proposal message appears to the online computer the user was annoyed by an action taken by that other user 

user who receives the proposal. that affected the first user. For example, suppose that a first 

FIG. 15 illustrates an example of how a Direct Play user sends a series of IMs to a buddy (a second user), but 

(computer game) proposal message would appear to the 35 after the third message, the buddy sends a message back 

online computer user who originates the proposal. requesting that the first user stop bothering the second user 

FIG. 16 illustrates an example of how a Direct Play with a11 these bo ™S messages. Despite this, the first user 

, . 4 , ,. continues to send messages. The second user becomes 

counterproposal message would appear to the online com- . , , . . t .? , r .. , 

• ■ • i i ju annoyed and decides to evil, or warn, the sender. Evil can be 

puter user who received the original proposal and who / , „ r ™ u A* • * j *u * i_ 

r ... , t -i r i employed generally on any ICBM. (It is noted that because 

responds with a counterproposal. Like reference numbers 40 a C]i ^ { Er * or mc ^ j/ nol an IC V BM> it cannot be eviled 

and designations in the various drawings indicate like ele- for feasons discussed ^ 

ments " A process for negotiating parameters using the Rendez- 

DETAILED DESCRIPTION vous P rot °col process is illustrated by the flowchart in FIG. 

3. A user (referred to as "the originator") who wishes to 

The present inventors have developed a negotiation 45 interact with one or more other users, for example, to set up 
protocol — referred to as the "Rendezvous" protocol — that a particular chat room environment, begins the Rendezvous 
provides a mechanism for negotiating between two or more session by sending a "Proposal" message to a buddy (step 
computer users to arrange a mutually beneficial communi- 301). The Proposal message contains the originator's pro- 
cation or multi-user interaction environment. One imple- posal for the desired interaction — in this example, a speci- 
mentation of the Rendezvous protocol is in the AOL Instant 50 fled chat room environment (e.g., topic, participants, etc.). 
Messenger (AIM) system, which allows users of a computer If at any time after sending a Proposal message (but prior 
network to exchange instant messages (IMs) or to engage in to the negotiation process ending as a result of some other 
a "chat" session, and further informs a user when any of that event, such as acceptance or timeout by the recipient), the 
user's buddies are online in order to facilitate direct con- originator wishes to cancel the proposal, this may be accom- 
versation. The Rendezvous protocol provides a general 55 plished by sending out a Cancel message (step 303). A 
framework that software developers can use to implement Cancel message allows the originator to provide a reason for 
various user-negotiation functionality in software applica- the cancellation. The three valid types of Cancel reasons 
tions. The AIM system, which allows users to chat, send IMs include "unknown", "user request", and "timeout". A normal 
back and forth, and transfer files, represents one specific cancellation, i.e., the originator changed his mind and does 
application of the Rendezvous protocol. In general, the 60 not desire to engage in an interaction, is denoted by speci- 
Rendezvous protocol typically operates within the standard fying the Cancel reason as "user request". "Timeout" is 
TCP/IP protocol, but any suitable protocol other than TCP/ given as the Cancel reason when the recipient fails to 
IP may be used instead. In this regard, protocols facilitating respond to the proposal in a timely manner and the originator 
a'reliable connection are preferable. gives up on waiting for a response and thus takes the 

The Rendezvous protocol adds a rich body of flexibility to 65 proposal off the table. If the reason for the Cancel message 

the event of chatting or otherwise interacting with another is not known, the Cancel reason field will indicate 

user. It recognizes that a user may wish to engage in a "unknown". 
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Assuming that the original proposal has not been 
cancelled, the recipient of the proposal may respond to the 
proposal in several different ways (step 305). One way in 
which the recipient may respond is to accept the proposal 
exactly as proposed by sending an Accept message (step 
307). This will cause the Rendezvous session to end suc- 
cessfully and allow the proposal originator and the proposal 
recipient to engage in the desired interaction (e.g., chat 
room) activity. It is noted that for the above implementation, 
the only way that a Rendezvous session can end successfully 
(i.e., the parties engage in an online activity which was 
agreed to via the Rendezvous session) is by way of an 
Accept message. However, depending on the objectives of 
the application developer, the Rendezvous protocol could be 
implemented such that other conditions (e.g., failure of 
recipient to object to a proposal under certain circumstances) 
could result in a successful termination. 

Another way for the recipient to respond is to reject the 
proposal by sending a Client Error message (step 309). A 
Client Error message has a field that informs the originator 
of the reason for the rejection. Possible reasons include the 
following: 

1) Proposal unsupported (e.g., recipient's computer is not 
configured to support) 

2) Proposal denied 

3) Proposal ignored 

4) Proposal timed out 

5) Busted parameters 

6) Online but not available/busy 

"Proposal unsupported" is an appropriate reason when the 
recipient's computer is not configured properly in order to 
engage in the proposed interaction. "Proposal denied" is an 
explicit rejection of the proposal, indicating that the pro- 
posal recipient prefers not to engage in the interaction. 
"Proposal ignored" indicates that the recipient has actively 
chosen to ignore the proposal. "Proposal timed out" indi- 
cates that the recipient has failed to respond within a certain 
amount of time. "Busted parameters" denotes that the pro- 
posal message itself cannot be understood, e.g., if the 
proposal message became garbled in transmission and hence 
cannot be read by the recipient's computer. "Online but not 
available/busy" is the appropriate response when the recipi- 
ent might otherwise be interested, but is too busy with other 
activities at that moment. For example, if the recipient is 
online because he is doing research for a project for work or 
school, and one of his buddies proposes that they play an 
online computer game, the recipient would most likely 
respond with a Client Error message specifying the reason 
"Online but not available/busy". The recipient can accom- 
plish this by setting a software switch that automatically 
responds with the "busy" message, for each proposal 
received. 

It is noted that, in this implementation, a Client Error 
message is the only type of Rendezvous message that cannot 
be eviled. All other Rendezvous message types are subject 
to eviling. The reason for this design decision is that 
allowing "evil" simply because a user has refused to engage 
in some interaction does not serve the purpose of "evil", 
which is to warn a user for abusing the computer resources. 
However, the Rendezvous protocol could be implemented 
such that any one or more of the available messages could 
be subject to evil, or not, depending on the implementor's 
objectives. 

Another possible response by the recipient is to modify 
the proposal by sending a Propose message back to the 
originator (step 311). This message contains a counterpro- 
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posal by the recipient. This is the basic means by which the 
two parties haggle over the details of the resultant chat room 
or other interaction (e.g., one-on-one games) environment. 
For example, suppose user A desires to play an, online 

5 computer game of bridge at the expert level with user B. 
User A proposes this to user B. However, user B prefers the 
intermediate level to the expert level, so user B sends a 
counterproposal to user A, proposing that the game be 
played at intermediate level instead. As a second example, 

10 suppose that user X and user Y are involved in a research 
project together, and they desire to enter a chat room in 
which their topic is often discussed. User X proposes to user 

Y that they meet together in a particular chat room that they 
have previously entered. However, user Y has heard about a 

15 different chat room that may offer better information, so user 

Y sends a counterproposal back to user X that they instead 
meet in the new chat room. 

Once a counterproposal has been sent, the recipient of the 
counterproposal has the same options (i.e., Accept, refuse 

20 via Client Error message, or send another counterproposal 
via a Propose message) as the recipient of the original 
proposal had upon receiving the original proposal. That is, 
the counterproposal effectively is treated as a new proposal. 
The sender of the counterproposal has the option of cancel- 

25 ling the counterproposal via a Cancel message, just as the 
original proposer had the option of cancelling the original 
proposal. In this way, the Rendezvous session can continue 
back and forth until the users either agree on some online 
activity, or one of them decides to end the session via a 

30 Client Error message. 

A representation of the Rendezvous protocol is provided 
in the Rendezvous State Transition Table, shown in FIG. 4. 
The State Transition Table lists the three possible states of a 
Rendezvous session: State 1 is that of the proposal origina- 

35 tor; state 2 is that of the proposal recipient, and state 3 is the 
end state, in which the Rendezvous session is terminated. 
Once a proposal is sent, thereby initiating a Rendezvous 
session, the proposal originator enters state 1 and the pro- 
posal recipient enters state 2. 

40 In state 1, one of five possible events will occur; these are 
represented by the five substates within state 1. If an Accept 
message is received (i.e., substate 1.1), the Rendezvous 
negotiation is successful, and the users go to substate 3.1, 
where the Rendezvous session ends and the agreed-upon 

45 online activity begins. If a Client Error message is received 
(i.e., substate 1.2), the Rendezvous negotiation is 
unsuccessful, and the users go to substate 3.2, where the 
Rendezvous session ends and the users discontinue their 
interaction. If a counterproposal is received (i.e., substate 

50 1.3), that user becomes the proposal recipient with respect to 
that counterproposal and thus enters state 2. If either a Time 
Out (substate 1.4) occurs, or a Cancel message is sent 
(substate 1.5), the negotiation session is cancelled by going 
to substate 3.3, where the Rendezvous session ends and the 

55 users discontinue their interaction. 

In state 2, four possible events can occur; these generally 
correspond with the five possible events listed in state 1 (the 
fourth event in state 2 (i.e., substate 2,4) corresponds to 
either of the fourth (substate 1.4) or fifth (substate 1.5) 

60 events in state 1). As the proposal recipient, the user in State 
2 can send either an Accept message (substate 2.1), a Client 
Error message (substate 2.2), or a counterproposal (substate 
2.3). The fourth possibility is the receipt of a Cancel 
message (substate 2.4). If an Accept message is sent, the 

65 Rendezvous negotiation is successful, and the users go to 
substate 3.1, where the Rendezvous session ends and the 
agreed-upon online activity begins. If a Client Error mes- 
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sage is sent, the Rendezvous negotiation is unsuccessful, and 
the users go to substate 3.2, where the Rendezvous session 
ends and the users discontinue their interaction. If a coun- 
terproposal is sent, that user becomes the proposal originator 
and thus enters state 1. If a Cancel message is received, the 
negotiation session is cancelled by going to substate 3.3, 
where the Rendezvous session ends and the users discon- 
tinue their interaction. 

In state 3, the Rendezvous session ends in one of three 
ways. A successful negotiation, substate 3.1, occurs when an 
Accept message is sent in response to a Proposal message. 
In this case, the two users will engage in the agreed-upon 
online interaction. An unsuccessful negotiation, substate 3.2, 
occurs when a Client Error message is sent in response to a 
Proposal message. In this case, the users that were involved 
in the Rendezvous session will discontinue their interaction. 
A cancelled negotiation, substate 3.3, occurs when a Cancel 
message is sent after a Proposal message was sent but prior 
to the receipt of a response. In this case, the users that were 
involved in the Rendezvous session will discontinue their 
interaction. In all three cases within state 3, the Rendezvous 
session is ended, as signified by the discontinued use of the 
Rendezvous "cookie", which is the unique identifier of that 
specific Rendezvous session. 

A diagram showing the components and format of a 
Rendezvous message (except for a Client Error message) is 
shown in FIG. 5. (Because a Client Error message is not an 
ICBM, it has its own format, described below.) Because a 
Rendezvous message is an ICBM payload, and because all 
ICBMs use the standard TCP/IP protocol, the first two fields 
501 and 503 in a Rendezvous message (other than a Client 
Error Message) are the TCP/IP header and the ICBM header. 
The ICBM header identifies the message as being a Ren- 
dezvous message. The next field 505 defines the Rendezvous 
Message Type and has a length of two bytes. Valid Message 
Types include Proposal, Cancel, and Accept. Valid data 
values for the fields shown in FIG. 5 are given in FIG. 6, As 
shown therein, the Message Type field can contain a "0" for 
a Proposal message, a "1" for a Cancel message, or a "2" for 
an Accept message. 

Referring again to FIG. 5, the next field 507 in the 
Rendezvous Message is eight bytes long and is called the 
Cookie. The Cookie serves as a unique identifier for a 
specific Rendezvous negotiation session; thus, all ICBMs 
that are part of the same Rendezvous session have the same 
Cookie, but a new Rendezvous session will have a new 
Cookie. 

The next field 509 is a 64-byte field called a UUID 
(Universal Unique Identifier). This field specifies the type of 
service desired. Referring again to FIG. 6, there are seven 
standard types of service that can be accessed with the 
Rendezvous protocol: "AOL Talk"; "Direct Play"; "File 
Transfer"; "Route Finder"; "Direct ICBM"; "Avatar 
Exchange"; and "Chat". Several of these services are avail- 
able in AOL Instant Messenger Version 2.0. (It is noted that 
only the first twelve characters of the UUIDs are shown in 
FIG. 6. For all seven UUIDs given, the last twenty charac- 
ters are 11D1^8222-444553540000.) "AOL Talk" refers to 
an AOL-compatible voice system that allows users to 
exchange audio messages with each other. "Direct Play" 
refers to playing an online computer game. "File Transfer" 
allows a computer file, such as a document, a spreadsheet, 
or a pictorial or graphical data file, to be transferred from one 
user to another. "Route Finder" allows users to find an 
Internet route for another application in a situation where a 
"firewall" is blocking the direct route to the desired appli- 
cation (e.g., if a user is online at the workplace, it is common 



10 



20 



25 



30 



35 



40 



45 



50 



55 



60 



65 



for employers to set up firewalls — software agents that block 
designated network traffic). "Direct ICBM" (i.e., sending 
ICBMs through a direct TCP/IP connection between the 
originator's and recipient's client computers) allows users to 
exchange IMs directly with each other without having to go 
through the primary server for the AIM system, thus afford- 
ing more speed and more privacy. It is noted that the Direct 
ICBM capability causes the users to lose the ability to use 
the "Evil" capability, and it also removes the protection 
against computer hackers that is normally provided by the 
primary AIM server. The Direct ICBM capability also may 
experience problems in penetrating firewalls. "Avatar 
Exchange" allows a user to exchange an image that typically 
represents the user's on-screen personality. "Avatar" is the 
term for this image, and it can be any graphical depiction, 
such as a cartoon, a drawing, or a photograph. "Chat" refers 
to a typical online dialogue in a chat room; this is typically 
performed by typing messages and sending them back and 
forth. 

The Rendezvous protocol is not limited to the seven 
standard service types described above. Possible implemen- 
tations include allowing user, for example, by accessing a 
special purpose users interface, to create their own UUIDs 
and corresponding applications. 

Referring again to FIG. 5, the next field 511 is a set of 
ordered triples, each ordered triple consisting of a Type, a 
Length, and a Value; hence, this field is referred to as the 
"TLV" field. The TLV field includes up to 15 reserved 
parameters, plus the application-specific parameters. Refer- 
ring to FIG. 7, which shows the 15 potential reserved 
parameters in the Type field and their corresponding 
numbers, the TLV field contains the information that is 
specifically being negotiated in the Rendezvous process. 
The first parameter in the TLV field is the "ICBM Channel" 
or equivalently, the "Rendezvous Channel". This parameter 
identifies the kind of ICBM being proposed, such as an 
online game or a chat. 

The next three parameters in the TLV field are called 
"Rendezvous IP Address", "Proposer IP Address", and 
"Verified IP Address". An IP address, or Internet Protocol 
address, is a unique identifier for any computer or virtual 
location on the Internet. The Rendezvous IP address is the IP 
address at which the proposed interaction would occur. The 
Proposer IP Address is the actual IP address of the origina- 
tor's computer. The Verified IP Address is the IP address of 
the originator's computer as seen by the primary AIM server. 
The verified IP address is different from the actual IP address 
when, as is sometimes the case, the computer associated 
with the actual IP address is behind an Address Translating 
Firewall to provide some protection against unauthorized 
use (i.e., computer hacking). In that situation, the use of a 
verified IP address allows users behind the firewall to 
communicate with others by having any responses directed 
to the verified IP address, rather than to the Proposer (i.e., 
actual) IP Address. The verified IP address also prevents 
"spoofing", which is the practice of providing another user 
with a false IP address. 

The next parameter in the TLV field is called "Port", 
which is the value of the Transfer Control Protocol (TCP) 
port for the Rendezvous Channel. More generally, a "port" 
is a logical channel identifier used by TCP. 

The next two parameters in the TLV field are called 
"Download URL" and "Verify Download URL" (URL- 
Universal Resource Locator; its specification can be found at 
RFC 1738). Download URL is an instruction to download 
the software or other data for whatever service is being 
proposed. Most Internet resources have a URL; URLs are 
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commonly referred to as Web site addresses, although URLs 
can point to resources other than Web sites. As an example, 
if the users desire to play a computer game, such as bridge, 
the bridge software must be downloaded to their personal 
computer workstations in order to participate in the game. 
Verify Download URL has the same basic information 
content as the previous parameter, but it may be added by the 
primary AIM server for protective reasons. 

The next parameter in the TLV field is called " Sequence 
Number", which is a one-up counter that iterates for each 
proposal within a specific Rendezvous negotiation session 
(i.e., all proposals and counterproposals having the same 
Rendezvous Cookie). The original proposal is given a 
sequence number equal to 1, the first counterproposal would 
be given a sequence number equal to 2, and so forth. 

The next parameter in the TLV field is called "Cancel 
Reason", which indicates the reason that a given Rendez- 
vous negotiation session is being cancelled. Valid reasons 
(described above) include "unknown", "user request", and 
"timeout". 

The next parameter in the TLV field is called "Invitation". 
This is an arbitrary text string and is generally used to 
communicate in human-readable language. For example, 
suppose user P desires to play a game of online chess with 
user Q. User P will send a Proposal message to user Q, and 
the Invitation might say, "Hey Q, how about a game of 
chess?" 

The last two reserved parameters in the TLV field are 
called "Invite Mime Character Set" and "Invite Mime Lan- 
guage". These parameters specify the character set and the 
language, respectively, that are used in the Invitation. Sup- 
ported character sets include "US-ASCII", "ISO-8859-1" 
and "UNICODE-2-0". For the Mime protocol, valid values 
are specified by ISO 639, ISO 3166, and RFC 1766. If 
desired, the country also may be included (e.g., English- 
UK). 

Lastly, referring once again to FIG. 5, the Rendezvous 
message contains a field 513 of application-specific param- 
eters. The application-specific parameters also are part of the 
TLV field, but their Type field falls outside of the reserved 
range (i.e., the first 15 parameters). These parameters 
depend upon the application or service to be accessed. For 
example, different computer games that can be played online 
typically will have differing sets of parameters in this field. 

As noted above, a Client Error Message is specifically 
excepted from the standard Rendezvous message format 
because it is designed to be not subject to "Evil". Although 
it is not an ICBM, it is a related message type referred to as 
an "ICBM Client Error" message. As such, it has its own 
data format, which is illustrated in FIG. 8. The first two 
fields 801 and 803 in any ICBM Client Error message are the 
TCP/IP header and the ICBM Client Error header. The next 
field 805 is the Cookie, which is the same value as in the 
Rendezvous messages within the same Rendezvous session 
(i.e., the Client Error Cookie necessarily has the identical 
value as the Cookie in the Proposal message to which the 
Client Error message is responding). The next field 807 is 
called ICBM Channel, which is the value of the channel on 
which the Rendezvous negotiation itself is occurring 
(usually equal to 2). (It is noted that in the Client Error 
context, the ICBM Channel field is different from the 
parameter of the same name in the TLV field of the Ren- 
dezvous message, where the ICBM Channel parameter 
refers to the channel where the proposed interaction would 
occur, not the channel where the Rendezvous negotiation 
itself is occurring.) 

The last field 809 is the Client Error Code. Referring to 
FIG. 9, the possible values for the Client Error Code are 
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given. These values correspond with the six possible reasons 
for a Client Error message, described above. 

FIGS. 10, 11, 12, 13, and 14 show examples of screen 
shots as seen by users of AIM during Rendezvous-related 

5 negotiations. As noted above, AIM is one specific imple- 
mentation of the Rendezvous protocol. FIG. 10 shows how 
a proposal message 1000 appears to the originator. In FIG. 
10, the proposed activity is a chat, and the screen name 1002 
of the intended recipient is "yipster666". The proposal 

10 message 1000 is transmitted to the recipient when the 
originator clicks on the "Send" button 1004 in the lower 
right-hand corner of the message box. 

FIG. 11 shows the proposal message 1100 as it appears to 
the recipient. The message box 1102 shows the screen name 

is 1104 of the proposal originator (in this case, "jimgromada"), 
the intended activity 1106 (a "Buddy Chat") the channel or 
location 1108 of the proposed activity (a chat room named 
"jag ChatOO"), and the textual invitation line 1110, "Join me 
in this Buddy Chat". The recipient has the option of accept- 

20 ing the proposal by clicking on the "Go Chat" button 1112 
in the lower right-hand corner, rejecting the proposal by 
clicking on the "Decline" button 1114, or causing the 
proposal to time out by not responding. (The option of 
modifying the proposal by presenting a counterproposal is 

25 not illustrated by this screen shot.) 

FIG. 12 shows a pop-up window 1200 that appears when 
the recipient decides to reject the proposal. This is the 
message box that appears on the recipient's screen as a result 
of clicking on the "Decline" button 1114. This "Decline 

30 Invitation" message 1200 will be transmitted to the proposal 
originator when the proposal recipient clicks on the "OK" 
button 1202. If the recipient wishes to "evil" the originator 
because the proposal is deemed offensive or annoying, the 
recipient may do this by clicking on the "Warn" button. The 

35 block button 1206 allows the receipt to block future pro- 
posals from this originator (jimgromada). 

In FIG. 13, the proposal originator has received the 
rejection message 1300 from the proposal recipient. Because 
this rejection message 1300 is by definition a Client Error 

40 message type, the proposal originator does not have the 
opportunity to "evil" the recipient, even though the proposal 
was rejected. The only option available to the proposal 
originator is to click the "OK" button. 

FIG. 14 shows a screen shot of a window 1400 that 

45 appears when a user receives a file transfer request from 
another user. File Transfer is one of the activities supported 
by the Rendezvous protocol. The recipient may either accept 
the file transfer request by clicking on "OK" 1402, or reject 
the request by clicking on "Cancel" 1404, corresponding to 

50 an acceptance and rejection, respectively, of the proposal 
(i.e., file transfer). 

In FIG. 15, a depiction of an online computer game 
proposal message 1500 is shown. The proposal originator 
1502, User__A, desires to play a particular game 1504 

55 (contract bridge) at an expert level 1510 with participants 
1506 (User_A and User_B). FIG. 15 illustrates how the 
proposal message would look as received by User _B, who 
has the opportunity to respond by clicking on the appropriate 
button at the bottom of the message box. If User_B is 

60 offended by the proposal, this can be registered by clicking 
on the "Warn" button 1512. If User_B would like to accept 
the proposal as tendered, the "Accept" 1514 button should 
be clicked. If User_B does not wish to play online bridge at 
all, the "Decline" button 1516 should be clicked (or the 

65 proposal will eventually be declined by timeout if User_B 
does not click on any buttons). If User_B wishes to play but 
disagrees with one or more of the parameters shown (e.g., 
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game 1504, participants 1506, type 1508, level 1510), the 
"Modify" button may be clicked to allow User_B to present 
a counterproposal. 

FIG. 16 shows how such a counterproposal box 1600 
might appear to the user desiring to modify the original 
proposal (i.e., User_B in the example depicted in both FIG. 
15 and FIG. 16). The originator 1602 is now User_B, 
because a counterproposal acts as a new proposal, and 
User_B is originating the counterproposal. It is noted that, 
because this counterproposal is part of the same Rendezvous 
negotiation session, the Cookie for the original proposal will 
be the same as the Cookie for the counterproposal. However, 
the Sequence Number for the original proposal will be equal 
to 1, and the Sequence Number for the counterproposal will 
be equal to 2. Both the Cookie and the Sequence Number are 
software parameters that are transparent to the users 
involved in the Rendezvous negotiation session. 

Referring again to FIG. 16, User_B agrees that playing 
online bridge with User _^A is desirable. However, User_B 
prefers a different type 1608 of bridge (duplicate bridge) 
rather than contract bridge, and User_B also prefers to play 
at the intermediate level 1610 rather than the expert level. 
Thus, these parameters have been modified in the counter- 
proposal message box 1600, which will be sent back to 
User_A. User_A will then have the same options for 
responding (i.e., Warn, Accept, Decline, or Modify), and the 
Rendezvous negotiation session will continue in that manner 
until it ends either with an acceptance (i.e., recipient of most 
recent proposal clicks "Accept"), a rejection (i.e., recipient 
of most recent proposal clicks "Decline"), or a cancellation 
(i.e., sender of most recent proposal cancels by clicking a 
"Cancel" button after sending proposal but before receiving 
response). 

Other implementations of and uses for the Rendezvous 
protocol described above are possible. In general, the Ren- 
dezvous protocol can be used whenever it is desirable to 
allow two or more users, or two or more client computers, 
to negotiate the parameters of a communication or interac- 
tion session. For example, the Rendezvous protocol could be 
used in e -commerce applications to allow buyers and sellers 
to haggle over price or other terms relating to an offer for the 
sale of goods, services, securities or any other tangible or 
intangible property. In addition, the Rendezvous protocol 
could be used in a collaborative project development envi- 
ronment (e.g., Lotus Domino) to negotiate changes to docu- 
ments and the like. 

The techniques, methods and systems described here may 
find applicability in any computing or processing environ- 
ment in which electronic content may be exchanged, 
viewed, accessed or otherwise manipulated. Various imple- 
mentations of the systems and techniques described here 
may be realized in digital electronic circuitry, or in computer 
hardware, firmware, software, or in combinations thereof. A 
system or other apparatus that uses one or more of the 
techniques and methods described here may be implemented 
as a computer-readable storage medium, configured with a 
computer program, where the storage medium so configured 
causes a computer system to operate on input and/or gen- 
erate output in a specific and predefined manner. Such a 
computer system may include one or more programmable 
processors that receive data and instructions from, and 
transmit data and instructions to, a data storage system, and 
suitable input and output devices. 

Each computer program may be implemented in a high- 
level procedural or object-oriented programming language, 
or in assembly or machine language if desired; and in any 
case, the language may be a compiled or interpreted lan- 
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guage. Suitable processors include, by way of example, both 
general and special purpose microprocessors. 

Generally, a processor will receive instructions and data 
from a read-only memory and/or a random access memory. 
Storage devices suitable for tangibly embodying computer 
program instructions and data include all forms of non- 
volatile memory, including semiconductor memory devices, 
such as EPROM, EEPROM, and flash memory devices; 
magnetic disks such as internal hard disks and removable 
disks; magneto-optical disks; and CD-ROM disks. 

Any of the foregoing may be supplemented by, or imple- 
mented in, specially-designed ASICs (application-specific 
integrated circuits). 

A number of embodiments of the present invention have 
been described. Nevertheless, it will be understood that 
various modifications may be made without departing from 
the spirit and scope of the invention. Accordingly, other 
embodiments are within the scope of the following claims. 

What is claimed is: 

1. A computer-implement method of facilitating interac- 
tions between users of a computer network, the method 
comprising: 

transmitting a first user's proposal for an activity to 
another user; the proposal comprising one or more 
parameters descriptive of the proposed activity; 

receiving a response from the other user, the response 
comprising a counterproposal having one or more 
parameters descriptive of the proposed activity, with at 
least one of the parameters of the counterproposal 
differing from a corresponding parameter of the pro- 
posal; and 

automatically engaging in the proposed activity using the 
parameters included in the counterproposal upon 
acceptance of the counterproposal by the first user. 

2. The method of claim 1 wherein the proposed activity 
comprises a chat session. 

3. The method of claim 2 wherein the parameters describe 
a proposed topic on which the chat session will be focused. 

4. The method of claim 2 wherein the parameters describe 
a proposed channel in which the chat session will take place. 

5. The method of claim 1 wherein the proposed activity 
comprises an online game. 

6. The method of claim 5 wherein the parameters specify 
proposed participants in the proposed online game. 

7. The method of claim 1 further comprising transmitting 
a response to the counterproposal, the counterproposal 
response comprising an acceptance, a rejection, or a second 
counterproposal. 

8. The method of claim 7 wherein a rejection indicates 
disagreement with at least one parameter of the proposal. 

9. The method of claim 7 wherein an acceptance indicates 
agreement to all parameters of the proposal. 

10. The method of claim 1 wherein the parameters are 
completely descriptive of the proposed activity. 

11. The method of claim 7 further comprising iteratively 
responding to further counterproposals until acceptance or 
rejection occurs. 

12. The method of claim 1 further comprising issuing a 
cancellation of a proposal or counterproposal. 

13. The method of claim 12 wherein the cancellation must 
be issued before acceptance or rejection of the proposal or 
counterproposal occurs. 

14. The method of claim 13 wherein the cancellation is 
transmitted by the user that transmitted the proposal or 
counterproposal to which the cancellation applies. 

15. The method of claim 14 wherein the cancellation 
includes a reason for the cancellation. 
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16. The method of claim 1 wherein the response can a cancel message type for withdrawing a proposal issued 
further comprise an ignore indication. in a previous proposal message. 

17. The method of claim 16 wherein receipt of the ignore 36. The negotiation protocol of claim 35 wherein the 
indication acts as a rejection of the proposal or counterpro- rejection message type indicates that the proposed activity 
posal. 5 was denied by a recipient of the proposal. 

18. The method of claim 16 wherein the ignore indication 37> ^ negotiation protocol of claim 35 wherein the 
is issued based on an explicit act by a user. rejection message type indicates that a recipient of the 

19. The : method of claim 16 wherein the ignore indication proposal explicitly ignored the proposal. 

is issued based on inaction by a user. 38 ^ lialion tocol of claim 35 wherein lhe 

20. The method of claim 1 further comprising transmitting fej . hn ^ in ' dicales timed-out, 
a message registenng displeasure with the counterproposal. J - n „, .• . i r ■ • L 

21. The method of claim 20 wherein the message regis- 39 - ™ e ne g° liatl °° P"* 0 ^ of claim 35 wherein the 
tering displeasure comprises an "Evil" message. P ro Pf Ml messa 8 e 'W* can be used to issue a counterpro- 

22. The method of claim 21 wherein an Evil message has P 053 ' messa S e m res P onse 10 a rece ! ved P ro P osal message, 
a cumulative effect upon a recipient's ability to use the me counterproposal message including at least one param- 
computer network 15 eter tnat dlffers " om tDe proposal message s parameters. 

23. The method of claim 22 wherein the cumulative effect 40 " ™ e "Ration protocol of claim 35 wherein the 
grows exponentially proposal, acceptance, rejection and cancel message types 

24. The method 'of claim 1 wherein the first user's c ™ be . used "> negotiate the parameters of one or more of 
proposal is based on text or data entered by the first user. following activities: exchanging voice messages, playing an 

25. The method of claim 24 wherein the first user's 20 onhn u e 8 ame ' findm g a r ° u,e from one chent computer to 
proposal is based on text entered by the first user. an0 ' her >. transferring files, direct instant messaging, 

26. The method of claim 1 wherein the response is exchanging avatars, or participating in a chat room, 
transmitted automatically. 41 - TOe negptoatimi Protocol of claim 35 wherein the 

27. The method of claim 1 wherein the proposal includes re j eclion m f u sa 8 e ^ indicates lhat ^ P"? 05 ^ ***** is 
an instant message. 25 unsu PP or t ec ' bv a cllent computer associated with a recipient 

28. The method of claim 1 wherein the response includes of the proposal. ......... 

an instant message 42, ^ negotiation protocol of claim 35 wherein the 

29. A computer-implemented method of producing an re i ec ! ion Q ? essa 8 e 'H* ! ndicates tnal tne P ro P osal messa S e 
optimal environment for an online activity involving two or could not be understood. 

more computer network users, the method comprising: 30 43 ' computer-based system for facihtating interactions 

c 4 4 . . c .. among users of a computer-network, the system comprising: 

allowing a first user to send a proposal for an online to r J * & 

activity to one or more other users, the proposal speci- two or more clieDt computers having software that allows 

fying parameters associated with the proposed online different users to interact with each other; and 

activity; and a negotiation protocol, supported by each of the client 

enabling the first user and one or more other users to computers, that allows users to negotiate parameters of 

negotiate the parameters of the proposal using coun- 10 online activity using counterproposals that modify 

terproposats that specify parameters associated with the parameters of the online activity. 

proposed online activity, with at least one of the coun- 44 • Th e system of claim 43 in which the software on the 

terproposal parameters differing from the parameters of client computers enables users to interact in one or more of 

the proposal, until an agreement is reached. the following activities: exchanging voice messages, playing 

30. The method of claim 29 wherein allowing a first user an online S ame » finding a route from one client computer to 
to send a proposal is implemented using a negotiation another, transferring files, direct instant messaging, 
protocol. exchanging avatars, or participating in a chat room. 

31. The method of claim 29 wherein negotiating param- 45 45. The system of claim 43 in which the client computer 
eters of the proposal comprises selectively exchanging one software comprises an instant messaging chent application, 
or more counterproposal messages until an acceptance or a 46. The system of claim 43 in which the negotiation 
rejection occurs. protocol comprises the following message types: 

32. The method of claim 29, wherein the online activity a proposal message type including parameters descriptive 
comprises one or more of the following activities: 5Q of a proposed activity; 

exchanging voice messages, playing an online game, an acceptance message type indicating agreement with all 

rinding a route from one client computer to another, parameters of a proposal; 

transferring files, direct instant messaging, exchanging a rejection message type indicating disagreement with at 

avatars, or participating in a chat room. least one of a proposal's parameters; and 

33. The method of claim 29, wherein the online activity 55 a cancd message type for withdrawing a proposal issued 
comprises e -commerce. m a previous proposal message. 

34. The method of claim 29, wherein the online activity 47 system of claim 46 in which ne g 0 tiation protocol 
comprises a collaborative effort on a project. messages are exchanged among users until mutually agree- 

35. A negotiation protocol for facilitating interactions a51e parameters of an online activity are established, 
between users on a computer network, the protocol com- 60 48 ^ system of claim 43 a software- 
prising: implemented mechanism for registering displeasure with a 

a proposal message type including parameters descriptive user's behavior during a negotiation session. 

of a proposed activity; 4 9, The system of claim 48 wherein the mechanism for 

an acceptance message type indicating agreement with all registering displeasure enables a user to affect another user's 

parameters of a proposal; 65 ability to access system resources, 

a rejection message type indicating disagreement with at 50. A computer protocol process for conducting a nego- 

least one of a proposal's parameters; and tiation between two or more online computer users, includ- 
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ing a first user and a second user, with the objective of 
engaging in a mutually desirable online activity in an 
environment having specified characteristics, the process 
comprising: 

(a) issuing a proposal message from the first user to the 
second user, the proposal message specifying the par- 
ticular environmental characteristics desired by the first 
user, 

(b) issuing a first response from the second user to the first 
user, the response comprising an accept message indi- 
cating agreement with the proposal, a reject message 
indicating disagreement with at least one aspect of the 
proposal, or a counterproposal offering to change one 
or more aspects of the proposal; 

(c) if the second user issues a counterproposal, issuing a 
second response from the first user to the second user, 
the second response comprising an accept message 
indicating agreement with the counterproposal, a reject 
message indicating disagreement with at least one 
aspect of the counterproposal, or another counterpro- 
posal offering to change one or more aspects of the 
counterproposal; and 

(d) repeating steps (b) and (c) until acceptance, rejection 
or cancellation occur, cancellation representing a with- 
drawal of a proposal or counterproposal. 

51. A computer-implemented method of facilitating 
e -commerce transactions between users of a computer 
network, the method comprising: 

transmitting to another user a first user's proposal for an 
e -commerce transaction; the proposal comprising one 
or more parameters descriptive of the proposed trans- 
action; 



receiving a response from the other user, the response 
comprising a counterproposal having one or more 
parameters descriptive of the proposed transaction, 
with at least one of the parameters of the counterpro- 
5 posal differing from the corresponding parameters of 
the proposal; and 
automatically completing the proposed transaction using 
the parameters included in the counterproposal upon 
acceptance of the counterproposal by the first user. 
io 52. The method of claim 51, wherein the e-commerce 
transaction comprises a sale/purchase of goods/services. 

53. The method of claim 51, wherein the e-commerce 
transaction comprises a sale/purchase of intangible property. 

54. The method of claim 51, wherein the parameters of the 
15 proposal comprise price, delivery details, model, style, 

color, and warranty details. 

55. Computer software, tangibly embodied in a computer- 
readable medium or propagated carrier signal, for facilitat- 
ing interaction among users of a computer network, the 

20 software comprising instructions for causing a computer 
system to perform the following operations: 

allow a first user to send a proposal for an online activity 
to one or more other users, the proposal specifying 
parameters associated with the proposed online activ- 
25 ity; and 

enable the first user and one or more other users to 
negotiate the parameters of the proposal using coun- 
terproposals that specify parameters associated with the 
proposed online activity, with at least one of the coun- 
30 terproposal parameters differing from the parameters of 
the proposal, until an agreement is reached. 
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